https://gibs.com RSS feeds for Global Internet Business Solutions ~ GIBS 60 https://gibs.com/Support/Knowledge-Base/ID/141/Changing_Web_Site_Name_in_IIS_7#Comments 0 https://gibs.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=51&ModuleID=411&ArticleID=141 https://gibs.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=141&PortalID=0&TabID=51 https://gibs.com/Support/Knowledge-Base/ID/141/Changing_Web_Site_Name_in_IIS_7 Recently I’ve had need to change the name of a running website in IIS 7. This isn’t something you can do through the GUI, but I have discovered you can do it through the command line and appcmd.exe, the IIS 7 command utility. It was as simple as: appcmd set site oldsitename.com -name:newsitename.com I didn’t even have to stop the site and everything carried on as normal. See the appcmd.exe link above to get more information on everything appcmd.exe can do. Sat, 30 Jul 2011 10:41:00 GMT f1397696-738c-4295-afcd-943feb885714:141 https://gibs.com/Support/Knowledge-Base/ID/153/Disabling_SSL_v2_and_weak_SSL_ciphers#Comments 0 https://gibs.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=51&ModuleID=411&ArticleID=153 https://gibs.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=153&PortalID=0&TabID=51 https://gibs.com/Support/Knowledge-Base/ID/153/Disabling_SSL_v2_and_weak_SSL_ciphers Disclaimer: The items mentioned in the following article involve making changes to your server’s registry. Incorrectly modifying your server’s registry can result in downtime or abnormal behavior causing unforeseen consequences. If you do not have much experience working with the registry or if you are not comfortable making these changes it is highly recommended that you seek assistance from an experienced Windows Server administrator. There are many issues that can cause a site to fail a PCI scan, but one of the most common reasons is having SSL version 2.0 and weak SSL ciphers enabled on the server. This is the standard default behavior on Windows Server 2003 so corrective action must be taken to disable these items. Weak SSL ciphers should already be disabled on Windows Server 2008 by default but you still have to disable SSL v2.0. You should ensure you have a full working backup of your server’s system state (which includes the registry) before making any of the following changes. To disable SSL v2.0 (necessary for Windows Server 2003 and 2008): 1. Click Start, click Run, type regedit, and click OK. 2. In the Registry Editor browse to the following location:  HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server * For Windows Server 2008 you first have to create the Server key so browse to this location:  HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0 a. Right click on the SSL 2.0 folder, select New, and click Key. b. Name the key exactly as shown: Server 3. Right click on the Server Key, select New, and click DWORD Value (the exact name on Windows Server 2008 is DWORD (32-bit) Value) 4. Name the key exactly as shown: Enabled 5. Verify that the key is set to type REG_DWORD with a Data value of 0×00000000 (0) 6. If you have a Windows 2003 Server you’ll need to follow the procedure outlined below for disabling weak SSL ciphers. If you have a Windows 2008 server you still need to reboot your server to force the changes to take effect but you are done making all necessary registry changes. To disable weak SSL ciphers (necessary for Windows 2003): 1. Click Start, click Run, type regedit, and click OK. 2. In the Registry Editor browse to the following location: HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers 3. Right click on the DES 56/56 key, select New, and click DWORD Value. 4. Name the key exactly as shown: Enabled 5. Verify that the key is set to type REG_DWORD with a Data value of 0×00000000 (0) 6. Repeat steps 3-5 for the following keys: RC2 40/120, RC4 40/128, RC4 56/128 7. Reboot your server to force these changes to take effect. Taking the above steps will correct PCI scanning issues related to having SSL v2 and weak SSL ciphers enabled. Mon, 07 Mar 2011 11:10:00 GMT f1397696-738c-4295-afcd-943feb885714:153 https://gibs.com/Support/Knowledge-Base/ID/156/Host_Headers__SSL#Comments 0 https://gibs.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=51&ModuleID=411&ArticleID=156 https://gibs.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=156&PortalID=0&TabID=51 https://gibs.com/Support/Knowledge-Base/ID/156/Host_Headers__SSL Configuring SSL Host Headers in Microsoft IIS Background Host headers can be used to host multiple secure web sites on one IP address. However, the same SSL certificate must be used for every site secured. That means that host headers can be used to secure multiple sites with SSL on one IP only by using certificates that are capable of covering more than one website (Wildcards or UC certificates). If multiple SSL certificates are used, the server will usually encounter problems providing the correct SSL certificate when an HTTPS connection is established, causing a certificate name error when connecting. A Wildcard will secure any subdomain of the domain that it was issued to. For example, a Wildcard SSL certificate issued to *.domain.com will cover something.domain.com, anything.domain.com, and whatever.domain.com. Because the *.domain.com certificate would be valid on any of these three domains, the server cannot supply the "wrong" SSL certificate. Similarly, a Unified Communications SSL certificate can include multiple fully-qualified domain names in one certificate, and, contrary to popular belief, are not exclusively for use with Microsoft Exchange servers. In fact, UC certificates are compatible with almost all major server types. The difference between UC certificates and Wildcard certificates is that while Wildcards work on multiple websites because of the * character in the domain name, UC certificates include a Subject-Alternative-Name (SAN) field that allows the certificate to include multiple names. For example, a UC certificate can be issued to include the names www.domain.com, www.domain2.com, www.domain3.com, and mail.domain3.com. That certificate could then be installed to all four sites. When connecting to any one of those sites, a browser will check the name that it is connecting to against the list of SAN names in the certificate. As long as a valid match is found, there will not be any error displayed. Setting up Host Headers and Secure Site Bindings in IIS 6 For IIS 7, please refer to our page discussing SSL Host Headers in IIS 7   Install your SSL certificate to the site to be used with secure bindings. If you have not already, configure the host headers of your site using IIS. In IIS, right click on a site you are securing and select properties. From the Web Site tab, click on "Advanced..." next to the IP address field. Click on your Default identity on TCP port 80, then choose "Edit" to enter your domain name as the "Host header value." Do this for any sites that will be sharing secure connections on the same IP. Next, you will need to open up a command line to set up your Secure Bindings. Go to Start > Run Type "cmd" and click "OK." Enter "cd C:\Inetpub\AdminScripts" to change to the IIS Scripts directory. If your system uses a different directory, go there instead. Enter the following command: cscript.exe adsutil.vbs set /w3svc/site identifier/SecureBindings ":443:host header" You can find the site identifier in IIS when viewing the list of all web sites from the IIS Manager in the Identifier column. The host header is the host header value that is assigned to the web site (e.g. digicert.com). If an invalid number is entered as the site identifier, you should get an error that "The path requested could not be found." Repeat the above step as many times as necessary to enable your SSL certificate to be used on the appropriate websites. If you need to enter the command for several sites, try using the DigiCert IIS 6 SSL Host Header Command Generator. You may need to restart the IIS sites for the changes to take effect. You can verify the configuration changes by opening each site in a web browser. If the wrong page is displayed for any URL, your SSL host headers have not been configured correctly. If you have trouble setting up host headers in IIS, you can also get around the issue by using different ports for your different secure sites (multiple secure sites can run on the same IP with different SSL certificates if they each use a different port), but most server administrators find that solution to be more trouble than it is worth. Tue, 25 Jan 2011 14:01:00 GMT f1397696-738c-4295-afcd-943feb885714:156